Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (0eb487a) 81.89% compared to head (a7b943d) 81.89%.
Report is 3 commits behind head on main.

This is just the sort of thing that comes out of nowhere and stops a release:

  C:\hostedtoolcache\windows\Python\3.9.13\x86\python.exe C:\Users\runneradmin\AppData\Local\Temp\pip-install-921_u8fz\llvmlite_bdff54372838458392dbf1151245b0b5\ffi\build.py
  CMake Warning (dev) at CMakeLists.txt:3 (project):
    cmake_minimum_required() should be called prior to this top-level project()
    call.  Please see the cmake-commands(7) manual for usage documentation of
    both commands.
  This warning is for project developers.  Use -Wno-dev to suppress it.

  CMake Error at CMakeLists.txt:3 (project):
    Generator

      Visual Studio 16 2019

    could not find any instance of Visual Studio.

Is it saying that we need just one more thing in CMakeLists.txt? If so, why did this never come up before, and why only on one version of one build?

Why, o why?

In fact, cmake_minimum_required() is called prior to the top-level project()!

@jpivarski no, that's a symptom that the build environment on Windows is not working -- we need to discover the C++ compilers to be able to proceed.

The OS is windows-latest and the arch is 32-bit -- my guess is that the windows image has updated and doesn't include VS compilers for 32-bit.

I'm spitballin' as they say, but I don't think it's necessarily a problem. We can check to see whether the windows image has changed, for example.

windows-latest is windows-2022, which doesn't sound like a recent update. Maybe that page is old. Perhaps we can explicitly set the Windows runner to windows-2019 or windows-2022 (on the assumption that the runner-images page is old).

I'll try windows-2019.

OK, it seems unlikely that the image has changed. I note that this fails later when trying to build llvmlite. I suspect this is because Numba no longer releases wheels for this platform - I know that they've just released a new version. But, I think that would be a red herring - we should see the same error in windows-latest. Let me see if cmake has changed.

This is ultimately being caused by pip trying to build an sdist of llvmlite because PyPI doesn't have a 32-bit wheel. I am content not to get to the bottom of why this happens, but I suspect the traceback is caused by llvmlite's internal detection logic (https://github.com/numba/llvmlite/blob/f22420ad768a31dd15ae45d551bb4e73907a27fa/ffi/build.py#L56). This follows from the fact that an awkward-cpp build succeeds in the same job (although it might use a different CMake from PyPI, that's irrelevant).

Off-hand I can't remember @jpivarski when we plan to drop 32-bit windows. It won't be hard to keep it running for now; we just need disable numba on win (32bit)

That's a good idea—dropping Numba on the 32-bit Windows test. I'll do that.

The Windows 32-bit test was historically very valuable in helping us eliminate cases in which we wrongly assumed that intp is int64 in our C++ code. There's no reason to test that with Numba, but it's good to keep testing it as long as we might edit the C++ code and Windows 32-bit is still a common enough platform to consider targeting.

You've also answered the "why now?" question: because Numba released 0.59.0 so recently.